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Amdt. dated April 10, 2008 

Reply to Office action of January 10, 2008 

REMARKS/ARGUMENTS 

Claims 1-13 remain in this application. 

The Examiner has rejected Claim 1 1 under 35 U.S.C. 101 . Claim 1 1 has been amended 
to obviate this rejection. 

The Examiner has rejected Claims 1-13 as being unpatentable over Bakre in view of 
Shionozaki. Applicants respectfully traverse this rejection. 

Referring to Bakre, there is disclosed a switch-based network architecture for IP multicast 
and integrated services. Bakre is directed to mapping IP and different levels of quality of service 
over an ATM network. Bakre, which is based on multicast switches, allow RSVP applications 
running on an ATM host to seamlessly participate in Internet wide multicast sessions. See 
column 1, lines 8-19. 

Bakre teaches a network architecture is constituted by one multicast switch per logical IP 
subnet in an ATM cloud. The multicast server in an ATM network allows aggregation of traffic 
for multiple senders that can be sent out on a single VC to the receivers. The multicast server is 
also capable of processing RSVP control messages in performing call emission control for RSVP 
flows. On the edges of the ATM cloud, border or edge multicast switches help to aggregate 
multicast receivers inside the ATM cloud for outside servers and vice versa. See column 8, lines 
47-65. 

Each multicast switch can communicate with all other multicast switches in the ATM 
cloud using a point to multipoint VC. The multicast switches constituted by switch hardware and 
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a switch controller that can establish the translation tables for cell forwarding. A multicast 
routing component of the multicast switch consists of three parts. The first part is responsible for 
maintaining group membership information for the logical IP subnets. The second part is 
responsible for communicating with its peer functions running another multicast switches in the 
ATM cloud. The third part of the multicast routing component provides an inter domain 
multicast routing protocol interface to EP routers located outside the ATM cloud. See column 9, 
lines 45-60. 

All the multicast switches in an ATM cloud initially form a mesh of point to multipoint 
among themselves. Once the control VCs are established, multicast forwarding within each 
logical IP subnet is performed as follows. A multicast address resolution server is employed in 
each logical IP subnet to resolve an EP multicast address to ATM addresses of the receivers that 
have joined the group represented by the multicast address. The multicast switch aggregates 
receivers within its logical IP subnet for outside sensors and outside receivers for local senders. 
To initiate quality of service-based multicast, a sender starts sending path messages to its local 
multicast switch. These path messages are formed over the improper and inter-logical IP subnet 
control VCs by the sender of multicast switches. Multicast switches combine the resource 
reservation requests from their local receivers and send an aggregate message to the senders 
multicast switch. The senders multicast switch collects requests from other multicast switches 
and its local receivers and forms an aggregate request to the sender. 

Reservations among multicast switches are handled using ATM signaling protocols, thus 
allowing the ATM network to best manage the quality of service and the path to multicast 
switches to multicast switches point to multipoint VCs. An RSVP soft state is maintained by the 
RSVP handler function of each multicast switch. RSVP requires routers to monitor RSVP flows 
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using inactivity timers and discard the state for flows that have not seen any traffic for a 
configured amount of time. 

As is evident from the above description, the entire teachings of Bakre are centered 
around and require a multicast switch in regard to an ATM cloud. The teachings of Bakre really 
have nothing at all to do with applicants' claimed invention. Furthermore, the Examiner cites 
figure 4, reference 16 as support for the limitation of sending connections to the network, with at 
least one of the output mechanisms nonmodifiable. However, referring specifically to figure 4 
and reference 16, it refers to a logical IP subnet control VC which emanates from its respective 
multicast switch to its respective ATM host. Referring to the text regarding figure 4, Bakre 
simply teaches that in figure 4, all the multicast switches and ATM cloud initially form a mesh of 
point-to-multipoint control VCs. Propagation of control messages from a multicast switch to the 
multicast receivers within the logical IP subnet is handled using separate point to multipoint 
control VCs 16. This inter-logical IP subnet control VC 16 is routed at the multicast switch in 
every multicast receiver and is added to the control VCs 16 as a leaf node when it first registers 
as a receiver with the local Mars for any multicast group. 

It is respectfully submitted by applicants, and also respectfully requested by applicants, 
for the Examiner to elaborate on how figure 4, reference 16 teaches or suggests the at least one of 
the output mechanisms are nonmodifiable, which is a critical limitation in applicants 1 claimed 
invention. 

Furthermore, applicants' invention of Claim 1 specifically has the limitation of switching 
permanent virtual connections. Applicants have taken the time in the specification to explain 
carefully, starting on page 7, line 14 the distinctions regarding permanent virtual paths and soft 
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permanent paths. There is no teaching or suggestion that Bakre has any capability, let alone 
need, or concern of switching permanent virtual connections. 

In regard to Shionozaki, the Examiner has simply cited Shionozaki for establishing 
releasing connections for SVC and PVC. However, there is no teaching or suggestion 
whatsoever how the establishing and the releasing of connections of SVC and PVCs taught by 
Shionozaki would be effected in some form or fashion by Bakre. It is respectfully submitted the 
Examiner is finding some arbitrary reference that has the teaching the Examiner recites, and 
simply applies it to Bakre to arrive at applicants' claimed invention. It is respectfully submitted 
this is using hindsight, which is improper and patent law. Applicants respectfully submit they 
did not discover permanent virtual connections or switched virtual connections, as found in 
Claim 8, but applicants submit that in the context of the switches as found in the claims, they are 
unique in handling or dealing with permanent virtual connections or switched virtual 
connections. 

Accordingly, Claims 1-13 are patentable over the applied art of record. 

In view of the foregoing amendments and remarks, it is respectfully requested that the 
outstanding rejections and objections to this application be reconsidered and withdrawn, and 
Claims 1-13, now in this application be allowed. 

Respectfully submitted, 
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